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I. Real Party in Interest 

The real party in interest for the referenced application is Sun Microsystems, Inc. ("Sun"). 
An Assignment transferring all interest in the referenced application from the inventors to Sun was 
filed with the USPTO on June 25, 2003. The Assignment is recorded at Reel 014243, Frame 0623. 

II. Related Appeals and Interferences 

To the best of the knowledge of the Appellant and the Appellant's legal representative, there 
are no other appeals or interferences that will directly affect, be affected by, or have a bearing on the 
decision of the Board of Patent Appeals and Interferences ("the Board") in this appeal. 

III. Status of Claims 

The present application, Serial No. 10/603,884 ("the '884 Application") was filed on June 
25, 2003. As filed, the '884 Application included claims 1-17. Claims 1, 8, 13, 16, and 17 were 
amended in a response to mailed to the USPTO on April 26, 2006. All of the pending claims, 
claims 1-17, were finally rejected in a final Office Action mailed on July 24, 2006. A Request for a 
Pre-Appeal Brief was filed with a Notice of Appeal on October 24, 2006. A Notice of Panel 
Decision from Pre-Appeal Brief was issued November 22, 2006, upholding the final rejection of 
claims 1-17. On December 26, 2006, a Reply under 37 C.F.R. § 1.116 was filed, addressing 
informalities noted by the Examiner. In the Reply under 37 C.F.R. § 1.116, Appellant amended 
claims 1,8, 13, 16, and 17 in accordance with the Examiner's suggestions. Accordingly, claims 1- 
17 are presently pending in the '884 Application. Of the pending claims, claims 1,13, 16, and 17 
are independent. 
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IV. Status of Amendments 

The claims were amended in a response to the Office Action dated January 26, 2006, filed 
on April 26, 2006. The amended claims were entered and considered in the final Office Action 
dated July 24, 2006. Subsequent to the final Office Action dated July 24, 2006, Appellant filed an 
Amendment after the Final Rejection (i.e., a Reply under 37 C.F.R. § 1.116), on December 26, 
2006. In a follow-up telephone conversation with the Examiner, the Examiner indicated that the 
amendments submitted on December 26, 2006, would be entered by the Examiner. Therefore, all 
amendments submitted to the Examiner during prosecution have been entered. The claims, as 
amended by Appellant and entered by the Examiner, are reflected in the claims included under 
Appendix A. 

V. Summary of Claimed Subject Matter 

Independent claim 1 relates to a system for specifying a consistency for an application. The 
system includes: (i) an application comprising a transaction, where the transaction comprises at least 
one of a plurality of states, at least one of a plurality of transitions, and at least one artifact, and (ii) a 
database operatively connected to the application. Further, the system requires: (i) that the 
application access data from the database associated with the at least one artifact using a consistency 
specification when the application enters the at least one of the plurality of the states, and (ii) that 
the consistency specification specifies at least one of a read consistency and a write consistency to 
apply to the at least one artifact. The system recited in independent claim 1 is discussed in at least 
paragraphs [0020], [0027]-[0030] and [0044] and Figures 2 and 3 of the '884 Application. 
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Independent claim 13 relates to a method for generating an application. The method 
includes: (i) obtaining a business object specification that defines ait least one artifact, (ii) obtaining 
an application usage specification that defines the application as a plurality of states and a plurality 
of transitions, where the at least one artifact is associated with one of the plurality of states, (iii) 
obtaining a consistency specification that corresponds to at least one transaction, where the at least 
one transaction comprises at least one of the plurality of states and one of the plurality of transitions 
and the consistency specification includes at least one of a read consistency and a write consistency 
to apply to the at least one artifact, and (iv) generating the application using a database schema, the 
application usage specification, and the consistency specification. Further, independent claim 13 
requires: (i) that the artifact be one selected from the group consisting of a variable, a relationship, 
and an attribute, and (ii) that the application access data from a database associated with the at least 
one artifact using the consistency specification when the application enters the at least one of the 
plurality of the states. The method recited in independent claim 13 is discussed in at least 
paragraphs [0018], [0020], and [0027] and Figure 3 of the '884 Application. 

Independent claim 16 relates to a computer-readable medium having recorded thereon 
instructions executable by a processor. The instructions include instructions for (i) obtaining a 
database schema that defines at least one artifact, (ii) obtaining an application usage specification 
that defines the application as a plurality of states and a plurality of transitions, where the at least 
one artifact is associated with one of the plurality of states, (iii) obtaining a consistency 
specification that corresponds to at least one transaction, where the at least one transaction 
comprises at least one of the plurality of states and one of the plurality of transitions and the 
consistency specification includes at least one of a read consistency and a write consistency to apply 
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to at least one artifact, and (iv) generating the application using the database schema, the application 
usage specification, and the consistency specification. Further, independent claim 16 requires that 
the application accesses data from a database associated with the at least one artifact using a 
consistency specification when the application enters the at least one of the plurality of the states. 
The aforementioned limitations recited in independent claim 16 are discussed in at least paragraphs 
[0018], [0020], [0023]-[0025], [0027], and [0044], as well as Figure 3 of the '884 Application. 

Independent claim 17 relates to an apparatus for generating an application. The apparatus 
includes (i) means for obtaining a database schema that defines at least one artifact {see, e.g., 
Specification, paragraphs [0018]-[0020], [0027], and Figure 3), (ii) means for obtaining an 
application usage specification that defines the application as a plurality of states and a plurality of 
transitions, where the at least one artifact is associated with one of the plurality of states {see, e.g., 
Specification, paragraphs [0018]-[0020] and Figure 3), (iii) means for obtaining a consistency 
specification that corresponds to at least one transaction, where the at least one transaction 
comprises at least one of the plurality of states and one of the plurality of transitions and the 
consistency specification includes at least one of a read consistency and a write consistency to apply 
to the at least one artifact {see, e.g., Specification, paragraphs [0018]-[0020], [0027], and Figure 3), 
and (iv) means for generating the application using the database schema, the application usage 
specification, and the consistency specification {see, e.g., Specification, paragraphs [0024]-[0025] 
and Figure 3). Further, independent claim 17 requires that (i) the artifact is one selected from the 
group consisting of a variable, a relationship, and an attribute {see, e.g., Specification, paragraph 
[0027]), and (ii) the application accesses data from a database associated with the at least one 
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artifact using a consistency specification when the application enters the at least one of the plurality 
of the states (see, e.g., Specification, paragraphs [0018]-[0020], [0030], [0044], and Figure 3). 

VI. Grounds of Rejection to be Reviewed on Appeal 

The sole ground of rejection to be reviewed on appeal is the rejection of claims 1-17 under 
35 U.S.C. § 102(b) as being anticipated by U.S. Patent No. 5,615,362 ("Jensen"). 

VII. Arguments 

In this appeal, the Appellant argues that claims 1-17 are patentable over Jensen for at least 
the reasons stated below. 

For the purposes of this appeal, claims 1-12 stand or fall together and claims 13-17 stand or 
fall together. Claim 1 is representative of the group including claims 1-12 and claim 13 is 
representative of the group including claims 13-17. 

Under 35 U.S.C. § 102(b), a person shall be entitled to a patent unless "the invention was 
patented or described in a printed publication in this or a foreign country or in public use or on sale 
in this country, more than one year prior to the date of the application for patent in the United 
States, ... ." Furthermore: 

Anticipation under 3 5 U.S.C. § 102 means lack of novelty, and is a 
question of fact. To anticipate, every element and limitation of the 
claimed invention must be found in a single prior art reference, 
arranged as in the claim. 

Brown v. 3M, 265 F.3d 1349, 1351 (Fed. Cir. 2001) (emphasis added). The Federal Circuit 
has held repeatedly that anticipation requires disclosure of each and every element of the claimed 
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invention in a single prior art reference. See, e.g., Schering Corp. v. Geneva Pharms., 339 F.3d 
1373, 1377 (Fed. Cir. 2003); Diversitech Corp. v. Century Steps, Inc., 850 F.2d 675, 677 (Fed. Cir. 
1988); Orthokinetics, Inc. v. Safety Travel Chairs, Inc., 806 F.2d 1565, 1574 (Fed. Cir. 1986). 

A. Claims 1-12 

Claim 1 is representative of this group. Accordingly, the following arguments with respect 
to claim 1 are similarly applicable to claims 2-12. 

Jensen does not disclose a transaction or a state 

Independent claim 1 requires, in part: "an application comprising a transaction, wherein the 
transaction comprises at least one of a plurality of states, at least one of a plurality of transitions, 
and at least one artifact." 

This limitation requires that the application includes a transaction, where the transaction 
includes a state, a transition, and an artifact. Further, the state corresponds to the state of the 
application. Said another way, the application at any given time is in a particular state. 

Turning to the rejection, the Examiner has asserted that transaction recited in the claim 
corresponds to an object instance {see Office Action mailed July 24, 2006, p. 3). Appellant 
respectfully disagrees. Specifically, Jensen defines an object instance as follows: 

w An "object instance" is an embodiment (instantiation) of an object 
class. Instances are differentiated from one another by their 
attribute values, but not their routines (capabilities) . For 
example, Jane Smith may be a first person-object instance and John 
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Doe may be a second person-object instance." (Jensen, col. 5, 11. 
50-57) 

From the above definition, the object instance is not equivalent to a transaction. Further, it 
would be improper for the Examiner to read the term "object instance" any broader than the specific 
(and unambiguous) definition provided within the cited prior art. Specifically, an object instance 
corresponds to a runtime instance of a class, which is composed of attributes. In contrast, the 
transaction, as recited in the claim, includes states and transitions, where the states are associated 
with the application. There is no mention that the object instance, as defined in Jensen, includes or 
contemplates a state or a transition, where the state is associated with an application. Again, any 
attempt by the Examiner to read the term clearly defined in Jensen more broadly is improper. 

The Examiner has also asserted that the term "state" as recited in the claims is equivalent to 
the term "state" that appears in Jensen (see Office Action mailed July 24, 2006, p. 3). Appellant 
respectfully disagrees. In particular, the term "state" used in Jensen corresponds to the state of a 
given piece of data (see Jensen, col. 9, 11. 20-26). In contrast, the term "state" as recited in the 
claims corresponds to the state of the application. Thus, the term "state" used in Jensen is clearly 
not equivalent to the term "state" recited in the claims. 

Moreover, the following passage of Jensen makes it clear that the term "state" is used to 
refer to the state of a given piece of data of an object instance, and not to a state of an application as 
required by the claimed invention. 

In the illustrated embodiment, each object instance also 
contains a reference count and state. Department instance 201 has 
attribute 203 which contains a reference count of 2, indicating that 
two variables in the object-oriented application refer to department 
instance 201, and a state of 1, indicating that the data associated 
with department instance 201 is valid, i.e., has been read since the 
last database transaction was committed. Employee instance 211 
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contains a reference count of 1 and a state of 1 in attribute 213. 
The reference count of 1 indicates that only one variable in the 
object-oriented application refers to employee instance 211. 
Employee instance 218 contains a reference count of 1 and a state of 
0 in attribute 220. The state of 0 indicates that the data 
associated with employee instance 218 has been flushed, i.e., has 
not been read since the last database transaction was committed. 
The reference count and state can be omitted in some embodiments 
(Jensen, col. 9, lines 23-35) 



Jensen does not disclose a consistency specification 

Independent claim 1 additionally requires, in part, that "wherein the consistency 
specification specifies at least one of a read consistency and a write consistency to apply to the at 
least one artifact." 



This limitation of the claim requires that the presence of a data structure (or file) that 
specifies one of the read consistency and the write consistency to apply to the artifact (see e.g., 
Specification, Code Samples 1-7). Turning to rejection, the Examiner has asserted that the 
following portion of Jensen teaches the this limitation (see Office Action mailed July 24, 2006, p. 
3): 

Second, it ensures that only one copy cf an object instance is in 
the cache at any given time, even if several different queries 
return the same information from the database. Third, the mechanism 
guarantees the integrity of data in the cache by locking data 
appropriately in the structured database during a database 
transaction, flushing cache data at the end of each transaction, and 
transparently re-reading the data and reacquiring the appropriate 
locks for an object instance whose data has been flushed. (Jensen, 
col. 4, 11. 41-49) 



A review of the portion of Jensen cited by the Examiner reveals no disclosure of a 
consistency specification (or any other data structure) that specifies one of the read consistency and 
the write consistency to apply to the artifact. In fact, the portion of Jensen cited by the Examiner is 
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directed to ensuring that the integrity of data in the cache without any disclosure of a specification 
that specifies one of the read consistency and the write consistency to apply to the artifact, where the 
artifact is used by the application. 

Moreover, in response to the Examiner's assertion that, "...locking data... suggests that the 
data is read only consistent, so the data can be assessed based on whether the data is locked or not, 
in other words read or write" {see Office Action mailed July 24, 2006, p. 10), Appellant respectfully 
asserts that the fact that Jensen supports the functionality to lock data overlooks the fact that the 
claims are directed to a consistency specification that defines the threshold decision of whether or 
not to lock the data. Said another way, the consistency specification defines how an application 
should use locking mechanisms to control the access of the data in a database, whereas Jensen is 
limited to disclosure of the locking mechanism itself. 

Jensen fails to disclose using a consistency specification to obtain data when the application 
enters a particular state 

Independent claim 1 additionally requires, in part, "wherein the application accesses data 
from the database associated with the at least one artifact using a consistency specification when the 
application enters the at least one of the plurality of the states." 

This limitation requires that the application accesses data associated with the artifact in 
accordance with the consistency specification when the application enters a particular state. Turning 
to the rejection, as discussed above, Jensen fails to disclose a state, where the state corresponds to a 
state within the application. Further, as discussed above, Jensen fails to disclose a consistency 
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specification. In view of Jensen's failure to disclose a state (as recited in the claims) and a 
consistency specification, it logically follows that Jensen also does not disclose using the 
consistency specification when entering a particular state within an application. 

Conclusion 

As Jensen does not disclose each and every element recited in independent claim 1 of the 
'884 Application, Jensen is not a proper anticipating reference under 35 U.S.C. § 102(b). See 
Brown, 265 F.3d at 1351. Accordingly, Jensen is also an improper anticipating reference for claims 
2-9 and 12, which depend, either directly or indirectly, from claim 1. Therefore, Appellant 
respectfully requests reversal of the rejection of claims 1-9 and 12 under 35 U.S.C. §102(b). 

B. Claims 13-17 

Claim 13 is representative of this group. Accordingly, the following arguments with respect 
to claim 13 are similarly applicable to claims 14-17. 

Jensen does not disclose a state or a transition 

Independent claim 13 requires, in part, "obtaining an application usage specification that 
defines the application as a plurality of states and a plurality of transitions, wherein the at least one 
artifact is associated with one of the plurality of states." 
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The above limitation clearly requires that an application includes a state and a transition, 
where an artifact is associated with the state. A state defines an interaction with a client, and as 
claimed, corresponds to the state of the application (see, e.g., Specification, paragraph [0028]). The 
Examiner asserts that in part, the following portions of Jensen teach this limitation (see Office 
Action mailed July 24, 2006, page 6): 

... and a state of 1 in attribute 213. The reference count of 1 
indicates that only one variable in the object-oriented application 
refers to employee instance 211. Employee instance 218 contains a 
reference count of 1 and a state of 0 in attribute 220 (Jensen, col. 
9, lines 22-31) 

However, the cited portion of Jensen refers to attributes and states of an object instance . As 
discussed above, an object instance corresponds to an instantiation of an object class, which is "a set 
of data (attributes) and functional capabilities (routines) encapsulated into a single logical entity" 
(see Jensen, col. 5, lines 45-49). The term "state" as used by Jensen corresponds to the state of any 
given piece of data of an object instance, and relates the data to other data (see Jensen, col. 9, lines 
20-26). In contrast, "state," as recited in the claims, corresponds to the state of the application. 
Thus, the term "state" used in Jensen is clearly not equivalent to the term "state" recited in the 
claims. 

Jensen does not disclose obtaining a consistency specification 

Independent claim 13 additionally requires, in part, "obtaining a consistency specification 
that corresponds to at least one transaction, wherein the at least one transaction comprises at least 
one of the plurality of states and one of the plurality of transitions and the consistency specification 



20039 1J 



14 



Application No.: 10/603,884 



Docket No.: 03226/305001; P9163 



includes at least one of a read consistency and a write consistency to apply to the at least one 
artifact." 



The above limitation requires that the consistency specification (e.g., a data structure or file) 
specifies one of a read consistency and a write consistency to apply to an artifact (i.e., a variable, 
relationship, attribute, etc.) within a transaction (see, e.g., Specification, paragraph [0027], Code 
samples 1-7). As discussed above, a consistency specifies how variables are to be read from or 
written to. The Examiner asserts that the following portions of Jensen teach this limitation (see 
Office Action mailed July 24, 2006, pages 6): 

... indicating that the data for these instances must be re-read from 
the database and the corresponding locks reacquired to ensure 
consistency of the data in the cache (Jensen, col. 12, lines 13-15) 

... The query (or queries) retrieves the appropriate information to 
update the data in the object instance and reacquires the 
appropriate database locks. The method then uses the row or rows 
returned to update the information in the object instance (Step CF) 
and sets (assigns) the state of the object instance to valid (Step 
CG) , indicating that the data in the object instance is valid, that 
is to say, guaranteed to be consistent with the corresponding 
information in the database (Jensen, col. 13, lines 1-9) 



It would be clear to one skilled in the art that the portions of Jensen cited by the Examiner reveal no 
disclosure of a consistency specification, or any data structure or file, which specifies one of the 
read consistency and the write consistency to apply to the artifact. In contrast, the portions of 
Jensen cited by the Examiner are directed to ensuring data integrity in a cache using a standard 
locking mechanism, and updating data in a database and ensuring internal consistency of the data, 
respectively. Said another way, the portions of Jensen cited by the Examiner merely disclose a 
mechanism for ensuring data integrity in a cache, but are completely silent with respect to a data 
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structure (i.e., the consistency specification) that defines how to apply the aforementioned 
mechanism for a given artifact based on the state of the application. 



Jensen does not disclose generating an application 

Independent claim 13 additionally requires, in part, "generating the application using a 
database schema, the application usage specification, and the consistency specification." The 
Examiner has asserted that the following portion of Jensen teaches this limitation (see Office Action 
mailed July 24, 2006, page 6): 

This mechanism uses an object model, database schema, and transform 
to define a mapping between the structured database and object 
instances of the application. Given these three inputs, it is 
possible to construct an object-oriented application that can 
retrieve information from the structured database according to the 
semantics of the object model. In particular, the application can 
retrieve a single object instance (that is, retrieve database 
information corresponding to a single object instance) using an 
object ID value, and can retrieve object instances related to a given 
object instance by following the relationship semantics of the object 
model and using foreign key mappings as specified by the transform 
(Jensen, col. 10, 11. 46-57) 



A review of the portion of Jensen cited by the Examiner reveals that there is no disclosure of using a 
database schema, an application usage specification, and a consistency specification to generate an 
application. More specifically, neither the object model nor the transformation corresponds to the 
consistency specification. The claim recites that the consistency specification "includes at least one 
of a read consistency and a write consistency to apply to the at least one artifact." In contrast, 
Jensen defines an object model as follows: 

An "object model" is a set of object classes that together form a 
blueprint for building an object-oriented application. Each object 
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class of an object model can have attributes, inheritances, and 
relationships. (Jensen, col. 5, 1. 66 - col. 6, 1. 2) 

From the above, it is clear that an object model does correspond to the consistency specification. 
Further, the "transform to define a mapping between the structured database and object instances of 
the application" (Jensen, col. 10, 11. 47-48) is also not equivalent to the consistency specification, 
because the consistency specification defines at least one of a read consistency and a write 
consistency to apply to the artifact. No such teaching is found in the cited prior art. 

Jensen does not disclose that the application accesses data from the database . . . using a consistency 
specification 

Independent claim 13 further requires, in part, that "the application accesses data from the 
database associated with the at least one artifact using a consistency specification when the 
application enters the at least one of the plurality of the states." 

As discussed above, Jensen fails to disclose a consistency specification, as well as a state, as 
required by the claimed invention. A consistency specifies how variables are to be read from or 
written to (see, e.g., Specification, paragraphs [0028]-[0029]). Examples of consistency 
specifications may be found, for example, in Code Samples 1-7 of the Specification. 

The Examiner asserts that the following portions of Jensen teach this limitation (see Office 
Action mailed July 24, 2006, page 3): 

Second, it. ensures that only one copy of an object instance is in 
the cache at any given time, even if several different queries 
return the same information from the database. Third, the mechanism 
guarantees the integrity of data in the cache by locking data 
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appropriately in the structured database during a database 
transaction, flushing cache data at the end of each transaction, and 
transparently re-reading the data and reacquiring the appropriate 
locks for an object instance whose data has been flushed (Jensen, 
col. 4, lines 41-49) 



In the illustrated embodiment, each object instance also contains a 
reference count and state. Department instance 201 has attribute 
203 which contains a reference count of 2, indicating that two 
variables in the object-oriented application refer to department 
instance 201, and a state of 1, indicating that the data associated 
with department instance 201 is valid, i.e., has been read since the 
last database transaction was committed. Employee instance 211 
contains a reference count of 1 and a state of 1 in attribute 213. 
The reference count of 1 indicates that only one variable in the 
object-oriented application refers to employee instance 211. 
Employee instance 218 contains a reference count of 1 and a state of 
0 in attribute 220. The state of 0 indicates that the data 
associated with employee instance 218 has been flushed, i.e., has 
not been read since the last database transaction was committed. 
The reference count and state can be omitted in some embodiments 
(Jensen, col. 9, lines 23-35) 



A review of the aforementioned portions of Jensen reveals that there is no disclosure of using a 
consistency specification to determine how to obtain data from a database when an application 
enters a given state] rather, the aforementioned portions of Jensen only teach that each object 
instance may be associated with a state. Moreover, even assuming arguendo that the 
aforementioned portions of Jensen teach the state of an application, there is no indication that the 
disclosed states are used to determine how to obtain data from a database when the state is entered. 
In contrast, the states merely serve to track the current status of the object instance (e.g., whether or 
not the data in the object instance is valid) without any indication that such information is used to 
dictate how to obtain data associated with the object instance. 
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Conclusion 

As Jensen does not disclose each and every element recited in independent claim 1 3 of the 
'884 Application, Jensen is not a proper anticipating reference under 35 U.S.C. §102(b). See 
Brown, 265 F.3d at 1351. Accordingly, Jensen is also an improper anticipating reference for claims 
14 and 15, which depend from independent claim 13. Further, Jensen is an improper anticipating 
reference for independent claims 16 and 17. Therefore, Appellant respectfully requests reversal of 
the rejection of claims 13-17 under 35 U.S.C. § 102(b). 
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VIII. Conclusion 

A copy of the claims involved in the present appeal is attached hereto as the Claims 
Appendix. As indicated above, the claims in the Claims Appendix include the amendments filed by 
Appellant on April 26, 2006, and on December 26, 2006. For the reasons presented above, claims 
1-17 are allowable over the cited prior art. Therefore, the Appellant respectfully requests that the 
Board reverse the Examiner's rejections and allow all pending claims 1-17 of the '884 Application. 
Please apply any charges not covered, or any credits, to Deposit Account 50-0591 (Reference No. 
03226/305001). 



Dated: January 24, 2007 Respectfully submitted, 



^pRobert P> Lord TFlo*-^ Sc tt*£Sfc- 

v Registration No.: 46,479 
OSHA • LIANG LLP 
1221 McKinney St., Suite 2800 
Houston, Texas 77010 
(713) 228-8600 
(713)228-8778 (Fax) 
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CLAIMS APPENDIX 

Claims Involved in the Appeal of Application Serial No. 10/603,884: 

1 . (Previously Presented) A system for specifying consistency for an application, comprising: 

an application comprising a transaction, wherein the transaction comprises at least one of a 
plurality of states, at least one of a plurality of transitions, and at least one artifact; 
and 

a database operatively connected to the application; 

wherein the application accesses data from the database associated with the at least one 
artifact using a consistency specification when the application enters the at least one 
of the plurality of the states; and 

wherein the consistency specification specifies at least one of a read consistency and a write 
consistency to apply to the at least one artifact. 

2. (Original) The system of claim 1, wherein the application is defined using an application 
usage specification. 

3. (Original) The system of claim 1, wherein the application is designed using an application 
usage specification and a business object specification. 

4. (Original) The system of claim 3, wherein the business object specification defines a 
variable of a business object. 
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5. (Original) The system of claim 4, wherein the business object specification defines how the 
business object is to be used in within the plurality of states and the plurality of transitions 
using the application usage specification. 



6. (Original) The system of claim 1, wherein the application is designed using an application 
usage specification and a database schema. 



7. (Original) The system of claim 6, wherein the database schema defines an attribute in a 
database schema. 



8. (Previously Presented) The system of claim 7, wherein the database schema defines how the 
attribute is applied within the plurality of states and the plurality of transitions using the 
application usage specification. 



9. (Original) The system of claim 1, wherein the database is a relational database. 



10, (Original) The system of claim 1, wherein the read consistency includes at least one selected 
from the group consisting of none, read once, re-read, and read consistent. 



11. (Original) The system of claim 1, wherein the write consistency includes at least one 
selected from the group consisting of none, creating an object, write over, write append, and 
write consistent. 
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12. (Original) The system of claim 1, wherein the artifact is one selected from the group 
consisting of a variable, an attribute, and a relationship. 

13. (Previously Presented) A method for generating an application, comprising: 
obtaining a business object specification that defines at least one artifact; 

obtaining an application usage specification that defines the application as a plurality of 
states and a plurality of transitions, wherein the at least one artifact is associated with 
one of the plurality of states; 

obtaining a consistency specification that corresponds to at least one transaction, wherein the 
at least one transaction comprises at least one of the plurality of states and one of the 
plurality of transitions and the consistency specification includes at least one of a 
read consistency and a write consistency to apply to the at least one artifact; and 

generating the application using a database schema, the application usage specification, and 
the consistency specification; 

wherein the artifact is one selected from the group consisting of a variable, a relationship, 
and an attribute 

wherein the application accesses data from a database associated with the at least one artifact 
using the consistency specification when the application enters the. at least one of the 
plurality of the states. 

14. (Original) The method of claim 13, wherein the read consistency includes at least one 
selected from the group consisting of none, read once, re-read, and read consistent. 
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15. (Original) The method of claim 13, wherein the write consistency includes at least one 
selected from the group consisting of none, creating an object, write over, write append, and 
write consistent. 

16. (Previously Presented) A computer-readable medium having recorded thereon instructions 
executable by a processor, the instructions for: 

obtaining a database schema that defines at least one artifact; 

obtaining an application usage specification that defines the application as a plurality of 
states and a plurality of transitions, wherein the at least one artifact is associated with 
one of the plurality of states; 

obtaining a consistency specification that corresponds to at least one transaction, wherein the 
at least one transaction comprises at least one of the plurality of states and one of the 
plurality of transitions and the consistency specification includes at least one of a 
read consistency and a write consistency to apply to at least one artifact; and 

generating the application using the database schema, the application usage specification, 
and the consistency specification, 

wherein the application accesses data from a database associated with the at least one artifact 
using a consistency specification when the application enters the at least one of the 
plurality of the states. 
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17. (Previously Presented) An apparatus for generating an application, comprising: 
means for obtaining a database schema that defines at least one artifact; 
means for obtaining an application usage specification that defines the application as a 
plurality of states and a plurality of transitions, wherein the at least one artifact is 
associated with one of the plurality of states; 
means for obtaining a consistency specification that corresponds to at least one transaction, 
wherein the at least one transaction comprises at least one of the plurality of states 
and one of the plurality of transitions and the consistency specification includes at 
least one of a read consistency and a write consistency to apply to the at least one 
artifact; and 

means for generating the application using the database schema, the application usage 

specification, and the consistency specification; 
wherein the artifact is one selected from the group consisting of a variable, a relationship, 

and an attribute, 

wherein the application accesses data from a database associated with the at least one artifact 
using a consistency specification when the application enters the at least one of the 
plurality of the states. 
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EVIDENCE APPENDIX 

No evidence is being submitted. 
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RELATED PROCEEDINGS APPENDIX 

No related proceedings are referenced in section II above, hence copies of decisions 
in related proceedings are not provided. This appendix is not applicable to the present appeal. 
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